Conventional user authentication techniques typically involve users authenticating to applications before being granted access to protected resources. Such authentication is based on user submission of a password or other authentication credential. For administrative reasons, the authenticating applications oftentimes communicate with a central authentication service maintaining credentials for multiple authorized users.
Passwords or other credentials submitted for user authentication may comprise one-time passwords (OTPs) generated by authentication tokens. Authentication tokens may be implemented as small, hand-held devices that display a series of passwords over time. A user equipped with such an authentication token reads the currently displayed password and enters it into a computer or other element of an authentication system as part of an authentication operation. This type of dynamic password arrangement offers a significant security improvement over authentication based on a static password.
Known authentication tokens include, for example, time-based tokens and event-based tokens. In a typical time-based token, the displayed passwords are based on a secret value and the time of day. A verifier with access to the secret value and a time of day clock can verify that a given presented password is valid. In a typical event-based token, the displayed passwords are based on a secret value and an event counter. The event counter may count the number of occurrences of a particular event, such as a user pressing a button on the token. A verifier with access to the secret value and the current event count can verify that a given presented password is valid. Other types of authentication tokens include challenge-response tokens, and hybrid tokens that incorporate various combinations of time-based, event-based and challenge-response techniques.
An example of a conventional authentication token is the RSA SecurID® authentication token, commercially available from RSA, The Security Division of EMC Corporation, of Bedford, Mass., U.S.A.
Passwords can be communicated directly from the authentication token to a computer or other element of an authentication system, instead of being displayed to the user. For example, a wired connection such as a universal serial bus (USB) interface may be used for this purpose. Wireless authentication tokens are also known. In such tokens, the passwords are wirelessly communicated to a computer or other element of an authentication system. Tokens having these wired or wireless communication arrangements are referred to as connected tokens, and save the user the trouble of reading the password from the display and manually entering it into the computer as in a disconnected token.
A number of different communication protocols have been developed recently for use by applications handling OTPs. One such protocol is described in M. Nyström, “The Protected One-Time Password Protocol (EAP-POTP),” IETF RFC 4793, February 2007, which is incorporated by reference herein. In protocols of this type, rather than communicating directly with a central authentication service, an application typically communicates with a relying party who, in turn, communicates with the central authentication service. The application receives an OTP from a user and sends information derived from the OTP to the relying party, rather than sending the OTP itself to the relying party. This can create problems in that the central authentication service may only be configured to validate OTPs and may not have any knowledge of protocol-specific OTP transforms.
Under conventional practice, in order to allow the central authentication service to validate OTP-derivative information submitted to it by the relying party, the service must be modified to be made aware of the details of the particular protocol used to generate that information. Moreover, the number of protocols to be supported and their associated details can change frequently. The resulting requirement for continuous incorporation of protocol-specific knowledge into the central authentication service substantially increases the cost and complexity associated with providing the service. It can also complicate the situation for relying parties as they may be forced to continuously update their interfaces to the authentication service.